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A PROGRAMMABLE PACKET DECODER 



Field of invention 

A p^et decoder assists a packet switch in identifying different types or. pircfcets-from- 
5 a data stream. Different types of packets have various lengths and headers located at 
different positions in different layers. The headers contain information needed by the 
switch, especially addresses. Also the data packets should be checked for errors, e.g. 
length errors and checksum errors. The packet decoder detects the types of packets and 
extracts pertinent information and inserts the result in the data st eam. The switch also 
10 receives control signals on a parallel control line from the packet decoder. 



Prior art 

A conventional solution is to use delay lines on which masks are applied to filter out 
the required information. A fixed packet decoder has only one mask. It has also been 
1 5 suggested to provide a packet decoder with several masks which can be selected to 
adapt the decoder for different types of packets. 



The invention 

The present invention does not use masks. Instead the decoder is programmed to make 
20 comparisons and the various operations by means of a program memory and a 
compare processor. 

- : The program memory has two parts. The first part of the program controls the 

detection of different types of packets and layers and also starts the proper saving 
. Z ' 25 procedure of the extracted information. This is the compare instruction memory. 

I* The other part of the program memory contains sub-routines fox controlling the 

operations on the information and saving of parts of the bit stream. This is the save 
* : instruction memory. 
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The packets arrive in a byte stream on a delay line, which is a shift register. In each 
clock cycle the byte stream is moved forward one step. A mux control unit detects Ihe 

start of a packet and also keeps track of every Byte^the-packerisT 

5 delay line. 

The compare processor receives instructions from the compare instruction memory. 
Since the compare processor is double-ported it may receive two instructions per clock 
cycle. Each instruction may fetch the correct byte or bytes from the delay line by 
10 means of the mux control. Depending on the instruction, the compare processor orders 
a save engine to perform two different save operations. 

In a bit save operation, the save instruction memory commands the bit save unit to 
perform one of three types of operations: a checksum control, a bit save, or a length 
15 error control. These are various check operations resulting in setting of flags in a result 
field. 

In case of a stream save, the save instruction memory commands the stream save unit 
to extract bytes to be saved in an option field. The stream save unit inserts the option 
20 field as well as the result field in the byte stream outgoing to th e switch. While the 
result field is inserted, the original byte stream is delayed in a 3 byte delay line. Also, 
control signals are sent on a parallel line to the switch. 

The packet decoder is programmed by means of higher level languages to be able to 
25 take care of different types of packets. The program memory may easily be expanded, 
if necessary. 

The invention is described in detail in the enclosed master thesis. 
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CLAIMS 

1 . A packet decoder detecting types of packets and extracting pertinent 
information from a data stream and inserting the result in the data stream as well as 
transmitting control signals on a parallel control line to a switch, whe rein-thopacket 

5 decoder is programmed to make comparisons and the various operations by means of a 
program memory and a compare processor. 

2. A packet decoder according to claim 1, wherein the program memory has two 
parts, the first part of the program controlling the detection of different types of 
packets and layers and also starting the proper saving procedure of the extracted 

10 information, the other part of the program memory containing sub-routines for 
controlling the operations on the information and saving of parts of the bit stream. 
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ABSTRACT 

The invention relates to packet decoder detecting types of packets and extracting 
pertinent information from a data stream. The packet decoder inserts the result in tie 

chtta^stream andrtransm^ 

5 According to the invention, the packet decoder is programmed to make comparisons 
and the various operations by means of a program memory and a compare processor. 
The program memory has two parts, the first part of the program controlling the 
detection of different types of packets and layers and also starting the proper saving 
procedure of the extracted information. The other part of the program memory 

■ 10 contains sub-routines for controlling the operations on the information and saving of 
parts of the bit stream. 
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1 Abstract 

This paper describes the development of a programmable packet decoder called 
Tiafcin. Tintin is primarily developed for ethernet traffic in gigabit speed, but 
support other packet based traffic aa well. 

Tte^nporftrTi ntin is a b yte w ide data ^treacrto brdeebdedir^he^nrtput^a- 

the same data stream with two additional fields, the result field ac d the option 
field, describing each packet. The contents of these fields are specified with 
Tintms specialized assembly language. 
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4 ETHERNET NETWORKING 



4 Ethernet networking 

There is much use of common network phrases in this paper. For those who is 
not fawntHftr with these, here is a basic network/ethernet description. 



-Protocol-suites 

To make computer network efficient! equipment from different vendors must be 
able to work together. To achieve this, a architecture standard for communica- 
tion must exist. Here is some examples of such standards. 



4.1.1 The OSI model 

For many years there were no good standard covering the whole communication 
aspect. In 1977 ISO established a group to develop such a standard. 1984 the 
ISO group suggested a layer model, called the Open Systems Interconnection 
(OSI) modeL It consisted of seven layers, all shown in figure 1. 



Application 
Presentation 



Session 



Transport 
Network 



Data link 



Physical 



Figure 1: The OSI environment 



A layer describes the kind of information exchanged on that level. The higher 
layer is transparent to lower layer and a layer on one level do net know that 
lower levels exists, e.g. the transport layer thinks it communicates vith another 
transport layers. In computer communication the rules of a layer ia i mplemen ted 
in a protocol. There might be many kinds of protocols on one layer, usually 
serving different purposes. 



4.1.2 The TCP/IP approach 

In the beginning the OSI model looked promising, many were those who thought 
the OSI model should exclude all other existing models. But this never bap- . 
pened, actually the opposite took place and the TCP/IP suite became one of 
the most used models. There are many reasons for the TCP/IP dcunination. 

1. The Internet uses the TCP/IP suite. This means there is much more 
equipment for TCP/IP, which lowers the price of such equipment. 
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4 ETHERNET NETWORKING 4.2 The packet concept 

2. The vendors da not always have time to wait for an standardiz-ition. When 
the OSI model took a long time to develop, the vendors used the existing 
protocols, such as TCP/IP. 

3. TCP/IP was developed by the U.S. military, who are big enough to control 
_ what tec b n i qnfl t h e vendors s h al l use. - 

The protocol suite for the TCP/IP suit is shown in the left part of figure 2. As 
seen there is only 4 layers in this stack The right part of figure 2 shows some 
protocols applied to each layer. 



Process/ 
application 



Host-Host 



Internet 



Network 
access 



FTP 




1 

==2 








TCP 






ip 




Network access 



Figure 2: The TCP/IP stack to the left And some corresponding interface? to 
the right. 



The layer in the OSI model is often referred to as layer 1 to layer 7 (LI to 
L7), where LI is the physical layer. In the TCP/IP stack there Is only 4 layers 
but they are not called L1-L4, as one may think. The lowest level in TCP/IP 
reaches much higher than the lowest level in the OSI models Therefore the 
lowest level is referred to as LI and L2. The next coming layer is however 
numbered sequential, L3-L5. This statement is not always true, but for the text 
in this paper it is assumed to be. 

4.1.3 Other protocol suits 

There exist a large amount of various protocol suites. Many of them are jiow 
considered obsolete but some still in use are Applet alk, Novell IPX ;ind DEC net. 
It is hard to predict what will happen in the future but it is safe to say that 
TCP/IP will grow. 

4.2 The packet concept 

All modern computer communication takes place with the exchange of packets. 
A packet contains a limited am mint of data, and several packets m;iy be needed 
to send the complete information. The data to be sent is encapsulated in several 
layers, e.g. the layers in the TCP/IP suite. The information in these layer is 
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4.3 A trpical packet 



MACdest 


MACsource 


0800 


IP fields 


06 


Rest of IP 


TCP 


Psyload 



fl 



f4 



> 4 *4 



f6 



P4 > 4 



f7 



f8 



A: The receivers MAC sririrrgB 
&l The senders MAC address. 
Q: The value 0x0800 tells thai L3 is IP. 
f4: The first fields in IP contains IP 
version, type of service and others. 



This field in the IP header tells that" 

Mia TCP. 
f5: The rest of the IP header cantaias 

IP addresses and others. 
f7: The TCP header. 
fS: The psyload, i. e. the information 

being sent 



Figure 3: A typical packet 

needed to route the packet to the correct receiver and for the receiver to know 
what kind of information it receives. 



4.3 A typical packet 

This chapter is called ethernet networking, but so far ethernet lias not even 
been mentioned. Ethernet is the lowest layer treated in this paper. It is said to 
be a L2 protocol, below ethernet there is the physical layer. There are several 
kinds of ethernet encapsulations (see appendix D) but they have many things 
in common. They always start with a six byte long MAG (medium access 
control) destination address followed by a six byte long MAC source address. 
Every ethernet network cards have a unique MAC address, this is needed for the 
network card to know which packets are addressed to itself. Except for the MAC 
fields every ethernet protocols have some information that specifies the typo of 
the next coming layer. On the Internet this often is IP (Internet Protocol), in 
other applications IPX is a common protocol. The third layer (1*3) contains, 
among others, routing information, which in IP is the IP destination and source 
addresses. There is a difference between the MAC and the IP addresses, the 
MAC address is used to route in local area networks (LAN) and the L3 address 
is used in bigger networks, so called wide area network (WAN). L3 also poiate 
out the next coming layer type, L4. At the Internet, TCP and UDP is common 
L4 types. A typical packet is shown in figure 3. 

4.4 Switches 

When several LAN:s or WAN:s shall exchange information there need to be some 
unit connecting the different LAN:s and WAN a- The unit must abto know how 
to send information between these different LANts and WAN:s. An intelligent 
type of such a unit is the switch. 

Here is one example of a switch task: 
A packet addresed with IP source address X arrives at one port. The switch 
must not onely know to which port this packet shall be sent. It also must know 
which source MAC address the receiver has and attach it to the packet. This 
knowledge can not be known by the sender since it is private to the LAN. 
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5 Specification of the master thesis 

In a switch (see 4.4) there ere several units and one of them is the decoding 
unit. The decoding unit is responsible for, which the name intimates, decoding 
the incoming packets. This means the unit put together information from the 
packets and gives it over to the rest of the switch e.g. which - LI! rL3~and L4~ 
protocols is being used, the IP source/dest. addresses they inherits and so on. 

Static packet decoders exist today but the task of this work were to produce 
a programmable packet decoder. A programmable decoder makes it easy to 
change/add protocols to the decoders tasks without fabricating a new ASIC 

In Swttchcores existing switch there exist a decoder. Howevur the design 
produced in this work can not directly be placed inside this since new features 
needs a new interface. The goal were to make the new interface leak as niTnifar 
to the existing as possible. 

Since the design can't fit the existing product it will be constructed as if 
it was to be produced on a separate chip. This involves work such as Ver- 
ilog coding, simulation, synthesis! timing analyzation, place & route and back 
annotated simulation. 

If this work should be god enough to use in a future product it has to support 
all features performed in the static design. These are: 

• Present which type of L2,L3 and L4 is being used in the current packet. 

• Extract fields from the packet needed by the rest of the switch. Examples 
of such information is TCP source/dest. ports, ethernet type, IP-TOS 
field, etc. 

• Perform checksum control on IP frames. 

• Report incorrect packets. 

• Report if the ethernet frame is of type VLAN tag or not. 

The information produced in the second point is presented in something called 
the Option field, this is a 18 byte long register. The information from the other 
points is presented in the Result field, which is a three byte wide : register. 

The maximal area to be used was 0.5mm 2 using a 0.25/xm process and the 
traffic arrives to the unit at 125 MHz. 
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6 The design process 

If an architecture is to be created, the first thing one often does is searching for 
published articles of the topic. This was done in this work as well, but nothing 
meaningful came up. So the work had to start from scratch, which mean a lot of 
analysts was needed ~As mentioned in the abstractra prestudy of Lhe topic was 
done during the course VLSI architecture, this was a help to avoid pitfalls. The 
basic architecture was done with pencil and paper, but it is hard to visualize 
all cases that can occur. Therefore a simulator, named Calculus, to test the 
architecture was created. 

Together with Calculus there was a need for other programs, all of them 
described in this chapter. All of the programs are written 1 C/C++. The 
implemented architecture was called Tin tin and the created softw.ire was given 
names from the Tintin stories. 

6.1 Calculus 

A first model of the architecture was made on paper and when the simulations 
started the evaluation of the first model led to the final solution. Very little 
knowledge of the physical sizes were known in the beginning of thn simulations, 
eg bit length of the registers and memory sizes. Therefore, Calciilua hade the 
possibility to change these parameters. The most crucial questioi, was the size 
of the delayline (discussed in chapter 7.3.1) and its muxable part. With a short 
delayline Tintin would not be able to handle many different protocols and a 
big delayline' would make area and timing constraints hard to meet. Many 
simulations with different sizes, new instructions and new functionality was 
made in Calculus. To be sure that the simulated architecture wis reasonable 
verUog code was implemented and synthesized for a rough timing analyze. The 
results from the simulations are described in section Architecture. 

There were one other advantage with Calculus, it was easy to study the 
efficiency of the program code. It is not a trivial task to write efficient code, 
but Calculus made it easy to trace and debug the code. 

6.2 Haddock 

To make the simulations meaningful (both for Tintin and Calculus) real program 
code was needed. In order to make programming easier a assemblatur, Haddock, 
was developed Haddock can handle labels, subroutines and remarks, which 
makes the code readable. The syntax for Haddock is described in Appendix B. 
Haddock made it possible to write and change the instruction coc.e fast. 
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6 THE DESIGN PROCESS 6.3 MtJou 




Figure 4: The simulator, Calculus 

6.3 Mllou 

Not only the program code was needed for the simulations, also real traffic was 
necessary. Therefore Milou, a packet generator was written. Milou randomly 
generate a packet consisting of L2, L3 V L4 and a pay Load. At layer two tiie 
following protocols can be generated: 

• IEEE 803.3/802.2 SNAP 

• Ethernet II 

• Netware 802.3 RAW 

• IEEE 802.3/802.2 
At layer tree: 

• IP 

• IPX 
At layer four: 

• TCP 

• UDP 
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6 THE DESIGN PHOCESS t'A Dupond 



other features axe: 

• Generate checksum error on IP headers. 

• Vary the payload and the inter frame gap. 

• Generate IP options field. 

■ Generate length errors In all layers. 

There are two output files from Milou, one that contains the data in decimal 
form and one file describing the generated data in text. 

6.4 Dupond 

Both TLntin and Calculus produces a resultfield, to make sure that this field ia 
correct when many (thousands) packets is decoded some sort of automatizend 
process i needed* The program Dupond was the solution for this. Dupond 
compares the resultfield from Calculus/Tintin and the text file from Milou. If 
there are errors in the result file, which ones and how many is reported. Dupond 
was a big help in debugging Tintin. 

6.5 Implementation 

When the simulations was done the architecture should be implennnited in Ver- 
Uog, which is a HDL language. When translating the simulated architecture 
some smaller problems occurred, some structures and instructions had to be 
changed to better fit in hardware. This made Calculus and Until incompati- 
ble and Calculus have not been updated since. Because no functional changes 
were made between Calculus ant Tintin all other programs could be used in the 
debuging work with Tintin. 

6.6 Floor planning and Place & Route 

After the synthesis, using Synopsis, there are some steps before sending the 
design for fabrication. This was done with Apollo and the process can be sen 
in picture 7. 

From the final step three files were exported, a verilog file, SDF file and a 
GDS file. The verilog file is a netlist for the whole design, it now consists of 
simple gates. The SDF file contains the timing information for all f;ates and the 
connections. The GDS file can be sent to a factory for manufactuiing. 

6.7 Back annotated simulation 

The first simulations of Tintin were made on verilog code on a veiy high level. 
When the code i synthesized errors can occur and the first simulations had no 
timing information. Therefore the construction was simulated again, this time 
using the verilog netlist and SDF files from Apollo. When this was done and 
no errors occurred it is safe to say that Tintin works in reality. 



Ingemar Hammarstrom 
Stig Halvarsson 



12 



a9 12/ 17 11:01 FAX 46 40 6119689 ALBIKNS KALMfl - PRV KASSAN ©019 

InU Patent- ochreg.veftel 
1999 -12- 1 7 

Huvudfaxen Kossan 

6 THE DESIGN PROCESS 6.7 Back sinnntattid simulation 




Figure 5: The compiler, Haddock 




Figure 6: The generator, Milou 
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6 THE DESIGN PROCESS 



6.7 Back annotated simulation 



@020 



Synthesize 



Verilognctlist 



FlooipIanniiLg 



Placement 



CTS 

HI 



Power routing 



Clock routing 

i 



Global 



Detailed routing 



Tfce first step after HDL coding is to syxrlbeszB, it 
converts high level code to a gste level cc-At. 



The synthesis tool generates * verolog net list, 
trTTrng bow to f^nw* til gstes. 

Divide* the chip in section* when the gxba andfidl 
custom block ii to be (faced. 



Places (be gates Is (he sections specified in last step. 



CTS (dock tree fjntoezalioo)* places and < intension 
buffers for (he clock tree. 



Mskcs (he cocmections Ibr the power. 
Mikes the cormcctiana for the etodc treeO) 
A ficst step in the routing process. 
The Lest step in fee routing process. 



LVS & DRC | LVS (Uycmt vs. schematic) checks (be fimrrion. 
■ J DKC (design rules check) checks fkb, rules. 



SDF 



Verilog 



GDSn 



Figure 7: Desdgnflow 
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7 The Tintin architecture 
7*1 The interface 
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- j 

DV • 

Cite Stream • 

1 

i 

4 


Tintin 

i i 

dock Rent 


t-OptisoFieUAitdicss 



j Figure 8: IO-interface 

i 



The input interface to Tintin is simple, there is one Hynchronous serial byte 
; stream for the data that should be decoded together with a 1-bit data valid 

| signal (DV) and also some used to program Tintin after power on. 

j The output interface consists of a serial byte stream together with some control 

signals. The control signals are a data valid(l bit), an option field address (6 
i bits), a store and a halt signal (1 bit each). The store signal tells if the current 

( byte is to be stored in the option field, the halt signal together with the store 

signal tells if the stream out is the inserted result field. The address bus allows 

addressing in the option field. 

The programming interface consist of an S-bit address bus, a 18-bit data bus, 
a chip select and a write enable signal for programming the two instruction 
memories and some specific registers described later in the text. 

7.2 How does it work 

When the data stream enters Tintin, it is passed through a delaiiine, see fig.9. 
This is a S3 shift deep and 1 byte wide ahiftregister. As long as a byte is in the 
first 16 positions it can be accessed by the compare processor, basically a parser. 
The compare processor is responsible for decoding the packets, r; is connected 
to a instruction memory which inherits the parsing code. 
| One basic property in the Tintin architecture is that every incoming byte is 

\ numbered with a tag. When the compare protestor asks for a specific tag the 

j mur control delivers the byte on that position. 

' When the parser have come to some kind of conclusion it might want to report 

. .* . something to the result field or the option field, see chapter 5. This is done by 

" * : - * starting up a save sequence. A start address for a save sequence will be sent 

• from the compare processor to the save engine. The Save engine examine the 

incoming address and decides if it is a save regarding the resu t field or the 
: : : option field. According to this decision the address is placed in either the bit 

* \ ' . ' save fifo or the stream save fifo respectively. 

* - t The bit save unit has three functions, it can set bits in the result field, perform 
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Tintin 




Figure 9: Block digram of Tintin 



checksumcontrol and lengthcontrol- The stream save unit execute the instruc- 
tion thai saves the option field. 

The stream save unit also inserts the result field in the stream and regulatea the 
control signals. 

7.3 Detailed description 

7.3.1 The Delayline 



Data to Compare Processor 




Figure 10: The Delayline with mux 

The delayline is rather simple, it consists of a 23 shift deep : 1 byte wide 
shiftregister. The 16 first positions of the shiftregister is reacluible from the 
compare processor through a mux. The two last positions are connected to 
the save blocka(6t£ save and stream save). The stream save bloJt is actually 
only using the very last position, only the bit save block needs the last two 
positions because the checksumcontrol works with 16 bits at a tirie. There are 
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five positions that can not be accessed either by the parser or the s£.veblocka(&if 
save and stream save). The reason for this delay before the byte stream arrives 
to the save blocks is that all start addresses sent from the compare processor to 
the saveblocks are cued in a fifo. In some extreme situations when many these 
five shifts may not be enough, which will generate an error. The actual delay 
to be sure that an er ror never wUl occiir is 4*64=192 clock-cyclta, 64 is th e 
maximum length of a save sequence and 4 is the maximum of start addresses 
waiting to be executed in one of the saveblocks, but the simulator, Calculus, 
have showed that five delay cycles is eno ugh. 



7.3.2 Mux control 



Compare Procetsor 



Ta&jnon 
Tsgjerror 
Too_ihort 
Halt 



Selected TAG 
Next packet 



Portion of TAG 
in Delayline 



Figure 11: The Mux controller 



A fundamental function for Tin tin is that it automatically keeps trade of 
where a specific byte has Its location in the delayline. The programmer only 
need to specify which tag, i.e. which number the byte has, where <<he first byte 
in a packet is number zero, the second is number 1 and so on. This Is why 
every byte arriving to the delayline is tagged (numbered). This could be done 
easily by just adding an extra field in every shift in the delayline inheriting the 
bytes tag. This is bad in two points of view, first much silicon would be used 
to implement the extra field in the delayline. Second, when the parser wants to 
look at a specific tag it would take a lot of time if every shift should, be searched 
to find the wanted tag. This is why an alternative implementation is used. 
The muxable part of the delayline is the 16 latest incoming bytes. Worst case 
for a packets length is 1 byte, but since the first 12 bytes always contain the 
MAC- address! no useful information can be extracted if the packet is shorter 
than 13 bytes. These packets will force the compare processor to begin with 
the next packet at once and their DV signal will be unset so tho rest of the 
switch will never see St. With a limit of at least two clock cycles (bytes) between 
different packets it is possible to guarantee that never more than two packets 
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7.3 Detailed description 



exist at the same time in the delayUne. According to the etheriet standard 
the IPG(Inter Frame Gap), which means the distance between packets, are at 
least 20 cycles, but a smaller distance is always desirable. E.g. with minim um 
distance of 6 cycles makes it possible to easy extend Tintin to be able to take 

care of SONET frames. ' . 

— The-mvz cmtivUer-iis^ (TagUnits), one for <tach possible 

packet, a CS (Controlling Statemachine) to control the TU:s and \ TU mux to 
choose which one of the TUzs that the compare processor is interested of. 
A TU consists of two registers (tagfield and the lastfield), some :iddexs and a 
rather simple statemachine. When a packet arrives, the tagfield starts to incre- 
ment for every byte. When the DV signal becomes false again the tagfield stops 
counting and the lastfield starts to increment. The TU sends an 'eid-of-packet' 
signal when the lastfield reaches the number of shifts In the deh.yline. If the 
packet was shorter than 13 bytes a 'toojshort' signal will be generated. 
The position of a requested byte is located according to 

p = tagfield + lastfield - wanted-tag 

The TU also generates a *tagjerror' if the requested tag never 'sill be avail- 
able or , tag-floon T if the requested tag has not arrived to the ddayline yet. 
The CS is responsible for selecting a free TU for an arriving pack** and and to 
pause the compare processor when no new packets are available. The CS will 
unselect a TU when the TU generates an 'end-aLpacket'. An uiiselected TU 
will be reset to prepare it to receive the next incoming packet. The CS is also 
controlling the TU mux to change its state every time the compart processor is 
asking for a new packet. 

7.3,3 The Compare processor 

The brain of Tintin is a programmable parser, see instructionaet in appendix 
A. It uses four registers to fulfill it tasks. 

• One PC register that hold the value of the program counter 

• One general register. It can be used with the instructions otr and ifr. 

• One base register, called basereg. When the parser searches a tag, the 
value in the basereg is added to the searched tag value. This is used 
to be able to reuse instructioncode for e.g. L3 frames, erven if they are 
encapsulated in different L2 frames. The instructions otr and aim can 
change this register. 

• One stack address register used to store addresses when subroutine in- 
struction is called with jsr. It is only possible to store one address hi the 
stack, rtn copy the stack back to the PC. 

All instructions are executed in one clockcycle, except in two case;. First when 
the received instruction is of type ifs or i/rn, then it compares the first data 
In thai block in the same cycle. Second when the next instruction is of type 
jas, jsr or rtn, then the PC is updated at once. This is possible because the 
compare processor unit receives two instruction b every clockcyde £:om a double 
ported memory. These two features decreases the total amount o:: clock cycles 
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Tag_error TAG-number 
Tag_?oon 
Halt 



Figure 12: The Compare Processor 



needed for the compare processor to parse a packet, thereby decreiLsing the size 
of the ddaylinc The if a and the jot instructions are able to start save sequences, 
these instructions have a field that tells what address in the save memory that 
shall start the execution. Save address 0x00 will not generate a start of a save 
sequence. 

The compare processor must know when a new parsing is started so the regis- 
ters can be reset. Therefore, when parsing of a packet is done, there shall be 
a jas instruction with jump address 0x7f (=last compare instruction memory 
address). When this is detected it resets and starts looking for a new packet. 
If the compare processor gets the signal *too.fihort' it is reset, 'tag.^oon* pauses 
the processor and 'tag-error' force it to begin with the next packet. 
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7.3 Detailed description 



7.3.4 Save engine 



From Compare Processor 



il^-, J-i 



Ji:oBlt_S„av«_ 



I'o Stream Save 



Figure 13: The Save Engine 

The save engine takes the address Bent from the compare processor and 
determine if it is the start address of a bit save sequence or a byte stream 
sequence. After this the address together with the current BASE is put in 
the specific fifo. The BASE is needed for all save instructions that is using 
tagmnnbera. When Tin tin is programmed, a constant is written to the save 
engine to tell where bit save sequences ends in the save memory. This feature 
exist because it is hard to tell how many instructions are needed to the the 
different parts and it is more expensive to map two memories than one twice as 
big. 



7.3.5 Bit save 



Stiff AddraiMt 
b Compare IVocmjot 



liiiilllH 



RemUAeld 



IsiiPlll 



•tor (Wayltoe 

Figure 14: The Bit Save processor 



To be Inserted In Data Sir 



The bat save unit writes to the result field The result field consist of 24 bitB 
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or 3 bytes. It is controlled by the save instruction memory and orders other 
units to execute the instructions. The executing unite are: 

• Checksum, this block executes the esc instruction which performs a 
16-bit one complement addition. The unit needs to know what tag to 

start the e^"***™ fromfTV^g) And h ow many byte s thejcfce<ksnTO^shouid^ 

cover(Length). If there are checksum errors (i.e the sum differs from 
QxFFFF) the unit writes to the result field. Which bit in the result field 
to write to is static and can not be changed by the programmer. 
Further this block need the value of the BASE as it was when the compare 
processor sent the start address of the current save sequence 

17 ifi is m ii 17 n in q a 7 — fi , 5 4 — 3 — 2 — 1 — 
10 Tag length 



• Bit, This unit executes the bis commands which bitwise 'xor' one selected 
byte in the result field with the data field. In other words, ill bits which 
are set in the data field will invert the corresponding bit in the result field. 
It is only possible to invert one specific bit one time per packet, this is 
because e.g. a L3 error could be found in many ways, but if the the bit 
which indicate L3 error is set an even number of times, th.,8 would look 
like a correct L3 packet in the result field. The address field tells to which 
one of the total three bytes In the result field to write to. 



17 1* 


i< 14 n 17 i \ in o 


8 


7 fx 




A 1 7 1 ft 


01 


Data 


Addr 


xxx>xx 



• Length error, this is the most complex unit and investigates lengths in 
a packet and Is used with the len instruction. In a network there might 
occur packets that has been cut of. This causes many sorts of errors, e.g. 
If layer 4 is shorter than two bytes the result field should indicate L3 error 
but not L2 error. 

The unit consists of two identical checkboxes and one controller. A check- 
box needs to know at which tag to start the measurement from, what 
kind of comparison it is supposed to perform (more^less or equal) and 
what length to match this comparison to! If a checkbox defects a length 
error, the field Addr tells to which one of four possible bits in the results 
field to write to. As with the checksum unit, this unit also needs the 
value from the BASE as it was when the compare processor sent the ntart 
address of the current save sequence. 
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7.3.6 Stream Save 
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Figure 15: The Stream Save processor 



Stream save has only one save instruction to handle, the baa. It is used to 
save to the option field and Includes a start tag number, a length txd an six bit 
wide a/jHr«xtfl to tell were in the option field the selected bytes are 1a be written. 
Besides of this it also inserts the result field as soon as all bit savu instructions 
are executed. 
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7.4 Programming Tintin 

The programming of Tintin is done trough the inputs PROGRAM DATA, PRO- 
GRAM ADDRESS, PROGRAM WE and PROGRAM CS, see Tintin will 
keep DV OUT low while CS is active. The memory mapping inside Tintin is 

shown in fig.16. 

On address QxFO the default result held is programmed. This is needed since 
some bits in the result field might indicate things that can't be detected, like 
no existing L4. This bit must instead get cleared when a legal L4 is found. 
The last register is needed for the Save Engine to decide weather an instruction 
is to he sent to the Bit Save or the Stream Save unit. 



0x00 


Compare Instruction memory 


0x7F 




0x80 
• 


Save Instruction memory 


• 

OxBF 




OxCO 


Number of Bit Save instructions 


OxCl 
0xC2 


Default resultfield 
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0xC3 
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Not used 
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Figure 16: Memory map 
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8 Results , limitations and further development 

The constrains from chapter 5 have been fulfilled. The area for :he total im- 
plementation, memory as well as logic, was 0,49mm 3 and can be clocked at 
140 MHz. These figures are god estimations of the real values since they are 
prodacedron a low le v el, much more exact than figures frcrm syrt 



During the work considerations to support ISL and SONET has been taken. 
They can not be direct supported but very little extra logic is needed, specially 
for SONET. 

Lgg till mer am Limmintations och fortsatfc utveckling. 
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A Instructionset 

A.1 Compare Processor 
IFM, IF stream with Mask 

-i-7— i* M iA-t.9- 



AddnPC [ 
Addr: PC+1 



000 



Cmp 



If length 



Tag 



-\ 2 1 0 



Mask 



Data 



IF (Condition True) then PC = PC + 2 

ELSE PC as PC + Ifiength + 2 

Cmp; Equal = 00 

LessThan = 01 
MoreThaa = 10 
NotEqual = 11 

Condition is True if Data relative to the masked streamdata, fulfill the Cmp specified. 
IFS, IF stream with several bytes and Save 



Addr PC 
Addr: PC+1 [ 



j o 



| 001 


Cmp 


Ifiength 


DL 


Save Address 


I Tagl 


Datal 



AddrPC+N 



TagN 



DataN 



IF (Condition True) then PC - 
ELSE PC^ 



PC + DL* + 1 

PC + DL* + Ifiength 4- 1 



Cmp: Equal = 00 

LessThan = 01 
MoxeThan = 10 
NotEqual = 11 

Condition Is True if Data relative to streamdata fulfill the Cmp ej^edfled. 
If Save Address differ from zero and IF (Condition True), 
then the save Address will be sent to the Save Processors. 

Data Length 
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A INSTRUCT! ONSET 



A.J Compare Proceusor 



IFR, IF Reg 

AddnPC 



■ If in — 

010 


XX 


If length 


X 


Mask 



IF ( (Reg & Mask)«0 )then PC^PO"! 



ELSE 

OTR, Operate To Reg 



PC = PC + Iflength 





17 Irt 


IS 


14 n 


1? 


11 


in o ft 


7 


* s 4 7 


1 0 


AddnPC 


011 


Src 


Dst 


X 


Operation 


Value 



Src: CmpBase ~ 0 , Source = BASE 
Reg = 1 , Source = REG 
Tag = 2 , Source = (Value) 
Konstant = 3 f Source = Value 

Dst: CmpBase = 0 , Destination = BASE 
Reg = 1 , Destination = KEG 

Operation: Add= 0 t Destination = Destination + Source 
Sub — 1 , Destination = Destination - Source 
Write ~ 2 Destination — Source 
Shift = 3 Destination = Destination \\ Source 
And — 4, Destination = Source & Destination 
Or = 5 , Destination = Source — Destination 

Note: Value is not always used 



ATM, Add T*s with Mask 

17 1* IS 14. H 19 11 1ft Q 

Addr:PC I 100 Tag 



? * « * * ? 1 0 



Mask 



Masks and adds streantdata with tagmimber Tag to BASE. 
J AS, Jump And Save 

17 Tfi IS 1A 11 19 11 1f1 Q 

AddnPC 



1010 



Save Address 



6. 5 -.4 3 2 1 0 



Jump Address 



PC = jump Address 
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A, I Compare Processor 



JSR, Jump and save to SubRoutine 

17 1* IS U n 13 II in Q 

AddnPC 



1011 



fi 7 



Save Address 



Jump Address 



STACK = PC 

PC = Jump Address 



RTN, ReTurN from subroutine 

17 ifi is 14 n i? ii in o 
AddrPC 110 XXXXXXXXXXXXXXX 



« 7 * 4 1 7 1 O 
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A.2 BHS&ve Processor 



A-2 BitSave Processor 
BIS, Bit Save 

n im^ 1 4 n n ii IDQ ft f 7 6, S 4 1 3 _ I Q 

-01- 



-Data 



Addr 



_xxxxx?:_ 



CSC, CheckSum Control 
17 ia i< li n n ii if) <> ft , 7 6 S 4 1 2 — I — CL- 



IO 



Tag 



Length 



LEN, LENgth control 

i< m n io n m o ft 7 a S dLpJ — 2-,-! — Q_ 



17 ifi 



11 



Tag 



Length Type | Addr 



HXT, HaLT 

^ ii i? n in q ft 7 & 5 4 — 3 2 1 — 0- 



11 



Ifi li 14 



xxxxxxxxxxxxxxxxx 



Note: All save sequences ends with a halt instruction. 
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A. 3 StreaasSave Processor 



A.3 StreamSave Processor 
BSS, Byte Stream Save 
17 \A K 14 n 10 11 m o a 7 S 4 2 — ? 1 0 
1 Tag 



Address 



Length 



HLT, HaliT 

17 in k u n n ii id It 7 M 4 3 — 2 1 — 0_ 

0 XXXXXXXXXXXXXXXXX 



Note: All save sequences ends with a halt instruction. 
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B Assembler syntax 
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C A program example 

Here is a programm fore Tiiitln that solves the same tasks as the ittatic design 
of today does. 



ft ********** Ma- TrT T/a ************************ 

: VLAK? ; 

lis eq OxOc.OxSl OxOd.OxOO ; save tag_save ; 
« to find oat if the packet is vlan tagged. 
< 

ifra eq 0xOe,Oxl0 ; moBic 0x10 ; 
•£ otr cone* regl write 0x01 ; 

# to remeaber that the packet has a RIF field 

> 

otr const coipbase write 0x04 ; 

# compensate for ED IF and TCI fields 

> 

if 6 It Ox0c,0x06 ; 

# find out witch L2 it is 

jas dummy. save HotEthll ; 

# It Is not Ethernet ir 

> 

jas EI I_ save detect.Ld ; 

# it is Bthernetll 

\> 

# ********** Main L3 ************************ 

: detect. L3 ; 

# Start detection of L3 
if 8 eq 0x0c t 0x08 ; 

# separate between ARP,RARP, IPv4, IPv6 and IPX 

< 

if s eq 0x0d»0x06 ; 
< 

jas dummy .save ARP.ex ; 

# ARP detected 

> 

lfs eq 0x03,0x35 ; 
{ 

jas dummy .save RARP.ex ; 

# RaRP detected 

} 

ifs eq 0x0d,0x00 ; 
i 

jas dummy.save IP. ex ; 

# IPv4 detected 

> 

jas dummy .save end ; 
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Oil the execution reaches this 
#polnt it is a unknown 13. 

} 

ifs eq 0x0c,Ox86 OxOd.Oxdd ; save IP. save ; 

_. f i s 

jas dmnmy.aave IPv6 .eat ; 
« IPv6 detcted 

> 

ifs eq 0xOc,0x8i Qx0d,0x37 ; save IPX,save ; 
i 

jas dummy.save IPX.ex ; 

# IPX detected 

> 

jas dummy .save end ; 

#If the execution reaches this 
tpoint it is a unknown 13. 

# **************** Not EII ****************** 

: Nat EthI I ; 

jsr dummy .save RIFF.length ; 

# subrutin call to take care of the RIF length. 
Its eq 0x0e,0xeQ OxOf ,0xe0 ; save noSNAP.save ; 

i 

# It is 602.3/802.2 with IPX 
ifs eq 0x10,0x03 ; ff mask 0x03 ; 

# This ifs-block finds out how long the LLc part is. 

-C 

otr const cmphase add 0x03 ; 

# compensate for the LLC field, 3 detected. 
^ jas IPX.save IPX.ex ; 

otr const cmpbase write 0x04 ; 

# compensate ior the LLC Held, 4 detected. 
Jas IPX.save IPX. ex ; 

> 

ifs eq Ox0e,0xaa OxOf ,0xaa 0x10*0x03 ; save SNAP.saire ; 
i 

# It ie SNAP. 

otr const cmpbase add 0x08 ; 
# compensate for the length, 
#idstring(AAAA03) and the org. code. 

jas dummy. save detect _13 ; 

> 

ifs eq 0x0e>0xff OxOf ,0xff ; save RAV.save ; 
< 

# netware ray with IPX. 
jas IPX.save IPX^ex ; 

> 

jas dummy. save end ; 

#the program should never reach this point, 
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C A PROGRAM EXAMPLE 



#if eo It la a unknown 12 
S ********** IPX extraction ***************** 

: IPX_ax ; 

#No IPX parsing ia done, 
jas dummy _save end ; 

fi ********** IPv6 extraction ***************** 

: IPv6. ex ; 

ftNo IPv6 parsing is done, 
jas dnnnny.save end ; 

# ********** ARp extraction ******** 

: ARP_ex ; 

#No ARP parsing is done . 
jas dmnmy_save end ; 

# ********** HARP extraction ******** 

; RABP.ex ; 

#No ft&RP parsing is done, 
jaa dumny.aave end ; 

# ********** ip extraction ******** 

: IP_ex j 1 
jar dnnoDy.aave RIFF. length, ; 

jas ip.eave nrow ; 
: nxov ; 

jaa I P_ stream nrow2 ; 
: nrov2 ; 

lfm eq 0x0e,0x40 ; mask 0x40 ; 

■ { 

jas is.v4 dumlabell ; 
: dmnlabell ; 

> 

: 14 ; 

if a eq 0x17,0x01 ; save 0THERl4.save ; 
jas dumny.Bave the _ end ; #L4 is I CMP 

> 

lis eq 0x17,0x02 ; save 0THER14_save ; 
{ 

jas dummy. save the _ end ; #L4 is IGMP 
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> 

its eq 0x17,0x06 ; save TCP-save ; 

jas dummy. save the.end ; #L4 id TCP 



1rf 



lis eq 0x17,0x11 ; save UDF.eava ; 

jos dumny.aave the. end ; #L4 la VDP 

} 

Job 0TRTC14_save the .end ; 
: the.end ; 
jas dummy .save end ; 
# ************ subroutln RIFF -part **************** 
: RIFF.length ; 
if r ; mask 0x01 j # RIFF ? 
{ 

rtn ; 

#no rif part, return iron subrontin. 

> 

ifm eq 0x0e,0x40 ; mask OxcO ; 

#Find out if there Is an KD field 

< 

otr const cmpbaae add 0x02 ; 

3RD field not precent, compensate for the R- field, 
jas dummy .save hack ; 

> 

atm OxOe Ox If ; 

#RD field is precent, reads RIFF lengt from strsam. 
: back ; 

otr const regl write 0x00 ; 

#Remove tag marker from register, 
rtn ; 



bit _ a ave_begin 

• dummy „savo ; 
hit ; 

: tag. save ; 
bis 0x02 0x01 ; 
hit ; 

: £1 1.eave ; 
bie 0x04 0x01 ; 
hit i 

: SNAP.save ; 
bis 0X06 0x01 i 
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hit i 

: noSNAP.e&ve ; 
bis 0x10 OzOl ; 
hit ; 



: RAV_save ; 
bis 0x0c 0x01 ; 
hit ; 

: IP.savo ; 
bis 0x01 0x01 ; 
bis 0x20 0x01 ; 
cbc OxOe 0x14 ; 
hit ; 



: IPX.save ; 

len OxOa Oxld mt 0x01 ; 

bis 0x01 0x01 ; 

bis 0x40 0x01 ; 

bis 0x20 0x02 ; 

hit ; 



: 0TBER14_eave ; 
bla 0x18 0x02 ; 
hit ; 



t TCP_oave ; 

len 0x18 0x09 mt 0x01 ; 

len 0x18 Oxld mt 0x02 ; 

bis 0x08 0x02 ; 

hit ; 



: UDP.eave ; 

len 0x18 0x09 mt 0x01 ; 

len 0x18 Oxll mt 0x02 ; 

bia 0x10 0x02 ; 

hit i 



: ie_v4 ; 

bla 0x01 0x02 ; 

hit ; 



bit.savc.and 



Btream_save.begin : 

IP. stream ; 

be a OxOe 0x00 0x14 ; 
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stroam_oave_end 

roault.f iold.default 0x123456 ; 
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D Common packets 



Untagged Ethernet frames 



TEM 8OU/803 J SNAP Ecaip»u^fl«o (RgC 1042) 

| PA I Sa ' I Length I AA AAM I O ig.coA. [ kTyyT 
1 — 5 — 1 — 5 — 1 3 "-^T 3 — 2 



Pup \ Cflg~| 



(RVC694) 





SA 


E>ypc 


fete 


1 CRC 1 
















lUtWm SOU HAW BwnpwHfina (PIC only) 






Da 


SA 




ffX-Checbnni 
1 3 


fete 

(wifltmrt IPX pTtfrlfFim) 


CRC 1 

1 — , 1 


6 

IEEE SO! 


1 — 5~ 

uvttui 


2 


bo 






[ DA | BA | Length 


I "* 1 


ISxm ™| CfoC 1 






6 


2 


3 or 4 







Of 

Ltngih 



Org. code 



DatkcOiOT MAC Addxes 
Source MAC Addioi 

LcdsQi of packet (cxch*fing DA. SA, Ltnfitb wd QIC) (m utt be fcolium'D60Q |( ) 

EtheaKtiypc of dats (afenyix-0600 ta ) 

0800.. * I? rintigmm 

0806,. -ARP 

0815 -RARP 

8137 ■ IPX dnfitgwn 

86DD H -IFv6 

A ftreebyte argoraxatiao coda. AD codes ire allowed. 



EPJCObedbtav The Cbeckmm of the IPX ftnnc. 
Urn Logical Hitfc eostroL 
E0 EO XX to (XX J - IPX. 

LLC 



Map 



SSAP 



T" 



I or 2 



O&f P Prginitiivi Service Access Foist 

SS^ Some SemoeAcceu Point 

Control Coataol fiekii (w« below) 



ate 



" By* I 






(o&ly pffcsc&t b I- md S-lbnnii 1 




PDUrt | 


WA | TVpe 


N/A | 



1 6 5 4 J a 



XD, - I-ftmn* PDU (2 byte Coated fidd) 

0 1 f S-fonnn PDU (2 bytes Coatml £eU> 

1 l a - U-Jbcmat PDU (1-bytc Control fidd) 

Typcofd*» 

Cydlfl Rednacbacy C beck of the entire etbernet fame 
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Tagged Ethernet frames 



5 — 5 — J 1 I Mo" 1 » a *» 




—5 



Offi 



13 



t PA I H A I WWII I TCI 1 Length 1 W \ ILU I D»a | CUC | 

1 — s — 1 — s — *— 3 — 1 — i — f a r 1 m» * 1 i«4 — — * — 



STPtD 

ra 



biti 16-14 Uxxr priori^ 7*0 (0 ii k»rat priority) 
bit IS CFT (Carats FccacttxJtcikx) 

mi • A2V field !• pcuvi io 0» Thf Bader 

met - Mo UP Odd b pnaei* 
bid 12-1 VXD (VLAN I cicada) 

000 • Mo VLAM fdniiflcr ii pxjx>t(uo]y Uacr priority) 

OOl^D eftatt _ 

Tie WF Sell to psoas if CTI t* «et. UV ii wed in o Tofcca Bias actvoilt to 
lift ftXFfijldloakl Ufa, 

Mr 

1 — 3 — 1 333 1 



oca dhti. 



b*» 16-14 £7010*100 typ«) 

(valki ki^tW: iTRT-OLX ( itenLIH it toO (aa>X«!*e 1-30 
Ml O.ObntmreH 

bit 1 N*J?i fiioixijBUtttu^ ft k i n il tndlat^ou) 

Roots Dacrfpu* (two byte* etch) 
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2 -MM? 
«-TCP 
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IP Data formal 

There en a number of $P tad* fermat* dopcoding oo eh* U^rotoce4 IWd m the U» header 



I. IP-PimocoJ-OUICMP 
Z IP-Protocol - OfiJ TCP 



TCP header 






TCP Header 


ii |i 1 1 fa 

|2 H4J5 


111 1 1 l» 12 |2 12 13 12 [2 11 |Z U 12 13 ]3 

6 l\I g J 9 A?JL)ii ' 3 ' li 5 JLll LtLiiJiJ 1 




c ronber 














1 Urgent pointer 







Source Port The TO tomt port 
Outbtatiom Pan The TCP dcanwtioo part 

SequMitce MvmbatdaSdtt <bo tint byto rn Che ttmxn of data tarn tending TCP to 
receiving TCP. 

«JdL number Kentiiie* the ncxl sequence aumbeftc* (be Kfioerof (hocknokdigBMnt 

S™** * tBBC,T TliB length of die header hi 32x1 weans. 

/tugj Six Saltan. Oao or more oca be tamed ao 01 the gaasim^ 

Fbgi 

luftp |aoc |hm lm& | yw \ m I 

URG: TV urgent pointer b valid, 

AOS; He Acknowledge sxuabcr a valid. 

PSH: TterccavoBboi^paiJ ^d^totbecppjkrtiawp. 

AST; React the panne criciL 

PIN: Tbe jendet U finiifrrd anwilgt daU, 

Ohrdbum Ccveo tie TtThcado- and data 
IftgMjKnater Hii to do arch (1m saqoesoe asxnber. 



UDP header 

UDP Header 



1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

0 1 1 |a [3 |<J5|« 17 If |9 loj 1 [MM*! 5 I* 


1 11 11 |2 |2 11 12 12 12 [2 2 12 11 13 13 
T |8 |9j0 1 J [2 h |4 |5 |fi 7ja|9|0|l 










f Data 



Soon* Pert TfceUDP«mceport 

Dagtiaatitm Port The UDP deatinatkm pact 

Length Ti* length of tbe UDP header and <Ua in byCem, 

Oteckjtm Oovcdttf UDP header and date. 



Tn gATriAy Hamznarstrorjtt 
Stig Halvarsaon 



41 



99 12/17 11:13 FAX 46 40 6119689 



ALttl&iS KALilO 



-> PRV KASSAN 



8)048 



Wet Patent- och reg-verkBt 
1999 -12- 1 7 

Huvudfoxen Kossan 



D COMMON PACKETS 



IPX Datagram 

IPX Dils{jia 

o i, u i, l f, u I, I. u liiiiii; 



i s u fVL U Ji U I' U 1^ I 




'Souses JtotT? 



Jndteato ft* tagft e/4it JPXfcrwfcrpObjtti) plwtfts «*&d diia. 

TbrKap Ctvkk Culii (Ui&ccJarcdifsTnn^uat Control field) hv&zltatkc cumber of tduceti at 
BHiliim procMMj dw padocti hoi nosced, Msxunralkip count <&Sea deperufisx whrtlirr RIP or 
NLSPtiwd 

Tbs Pocket qp* field mi femted to define the typo of ooamamiottoa (SPX.NCP. SAP. (UP and 
ao oq). Hki field, boweve/, hit reaDy been aaicd up over ifct yem. Iht only wtlaci (fan on: 



■ cul UtstloctioB KC^et numben. 



5«SPX 
10 -NetBIOS 

Tfaefautwqyto Weaejy 0 packet M by *■ * 

DtttlttcHim NehmkAdbmu 

Inrftotm ftc flnri <tenhmafcia nctwort ftrQapitcfcct. 
DcslUartim Nuti* Addrcu 

t n dic al gi tb* nod« a&lrtu (or fcc«l ID ronton) artha Jtsfe mrre o dsvic*. 
DnHiuotitm Suatrt Ntmbrr 

Socket amsfcen iadkam tfao cod ptdcbu tfcat tin paektt « dtstued fbrorthes 

created (he packet Somu mimwm irofcct curabcti; 

Q*5J = WP 
04a* -NetBIOS 
900l„ »HLSP 
3*«o*r Nttwort Addrtxi 

Indicates Ad Bstwock (hot tbs packet li bcicg tcsi ft>on> 

todiCatci ttic node tiddicn (ox host ID B^nbo^ oX It 

Sue dcnlptioB uf Otadnttua Sodut Nsakxr. 



a proof u f bctf 
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E Time schedule 
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